REMARKS 

In the Office Action mailed September 27, 2007 claims 1-3, 5-20, 35-37, 58 and 60-75 
are currently pending. The disclosure of the specification stands objected to because of various 
alleged informalities. Claims 11, 16-17 and 68 stand objected to due to various informalities. 

Claims 1-3, 5, 7-20, 35-37, 58 and 60-75 stand rejected under 35 U.S.C. § 102(e) as 
being allegedly anticipated by Barton et al. (US Publication No. 2003/0095791) ("Barton 791"). 
Claim 6 stands rejected under 35 U.S.C. § 103(a) as being allegedly unpatentable over Barton et 
al. (US Publication No. 2003/0095791), as applied to claim 2, in view of Sull et al. (US 
Publication No. 2006/0064716) ("Sull 716"). 

Applicants respectively traverse. After a careful review of the pending Office Action, the 
cited references, and Applicants' clarifications to the presently pending claims, Applicants 
respectively request reconsideration in view of the following remarks. 

I. OBJECTIONS TO THE SPECIFICATION 

The disclosure of the specification is objected to because of informalities. Specifically, 
the present Office Action objects to the failure of the present specification to include the various 
serial numbers in paragraphs [0005] and [0006]. Applicants have modified these paragraphs 
with the desired information and therefore respectively request that these objections be 
withdrawn. 

II. CLAIM OBJECTIONS 

Claims 11, 16-17 and 68 stand objected to due to various alleged informalities. As 
suggested by the presently pending Office Actions, revisions to these claims have been made. 
Accordingly, Applicants respectively request that these objections be withdrawn. 



III. 



CLAIM REJECTIONS UNDER 35 U.S.C. $ 102(e) 



Claims 1-3, 5, 7-20, 35-37, 58 and 60-75 are rejected under 35 U.S.C. 102(e) as being 
allegedly anticipated by Barton et al. (US Publication No. 2003/0095791). 

A. Applicants ' Presently Claimed Invention 

Applicants' presently claimed invention relates generally to enabling web users easy 
access and control of media-based devices and appliances over computer networks, and more 
specifically, to a method, system and computer medium for remote control of a digital video 
recorder from a client user interface both in communication with the internet. Applicants' 
Specification pg. 2, \ [0007]. 

Importantly, and as Applicants explain referring to the block diagrams of FIGs. 3 and 4B, 
the servers 28-1 through 28-n included in an embodiment of network computing system 12a are 
described in detail. For convenience and ease of understanding the invention, reference will 
interchangeably be made to "servers 28" to generically describe features of servers 28-1 through 
28-n. Also for convenience, like reference numerals have been used for similar components used 
in both the client computer 18, and the servers 28. Servers 28 are generally responsible for 
presenting the front end 14a of computer system 1 OA to a user at the client 18. In one 
embodiment, servers 28 may be web portals, which is defined to mean a web "supersite" that 
provides a variety of online services. Alternatively, servers 28 may be web-sites provided by 
and/or web-hosted by unrelated entities and system administrators. These particular 
embodiments are well-suited for the situation when network 24 is the Internet. Applicants' 
Specification pg. 27, If [0091]. 

Referring to FIG. 4B, Applicants explain further details of a particular embodiment of a 
main memory unit 78B for a server 28 are shown, by way of example. In the embodiment of 



FIG. 4B, the memory unit 78B preferably comprises an operating system 88, other applications 
90, server application programs 92 ("servers 92"), and a "front end" server application 94, all 
communicatively coupled together via system bus 74. Server 92 may be any conventionally 
known server application, like for example, and Apache HTTP server. Front end server 
application 94 is an interface for establishing communication with the middle tier server 40 by 
sending and receiving requests and data to the API. In general, servers 28 may host front end 
14a and are typically external websites relative to systems 14a and 16a. Because servers 28 can 
represent a variety of general purpose websites, some functioning as a "supersite" that provide 
various online services, while others being for more limited purposes, for convenience and to 
avoid obscuring the invention with unnecessary details, reference to server 28 will 
interchangeably be made herein to "web portals 280." Applicants' Specification pg. 28, Tf 
[0093]. 

Applicants' FIG. 13A presents a data flow diagram illustrating the process 230 of one 
method for a user to obtain information from and provide instructions to systems 10A and 10B. 
FIG 13B is a sequence diagram illustrating further details regarding the data flow of FIG. 13 A. 
Throughout this figure, data flow lines (used interchangeably with "steps") reflect an order in 
which part of the method is preferably practiced. In the description to follow, occasional 
reference will also be made to FIGs. 2 and 5. Before the process 230 of obtaining information 
from and providing instructions to system 10A and 10B begins, a user navigates to 229 a website 
for one of the servers 28-1 , . . .m 28-n, which responds with an appropriate web page 23 1 . The 
process 230 begins with the user login 232 into system 10A or 10B. A user enters identifying 
information, as for example, in the user interface 180 of FIG. 1 1. A user name and password are 
transmitted from the client browser to the database as indicated by steps 232, 234 and 236 in Fig. 



13B. Once the user is authenticated with predetermined information on the database, a first page 
190 of information such as an EPG is shown in Fig. 12A is formation 240 from data received 
from the database 238, and is forwarded 242 to client browser 20. Such first page 190 of 
information, as well as subsequent pages, may include drop-down menus such as those 
illustrated in FIG. 12B, as well as buttons such as the "Go" button 192 seen in FIG. 12A. The 
user may select a desirable entry within each drop-down menu and/or click on the "Go" button 
192 to invoke a command. Upon doing so, the browser 20 sends a HTTP request to an already 
connected web server such as 28-1, as shown in step 232. Those skilled in the art will recognize 
that the drop-down menu and button-driven features may be implemented in a variety of ways. 
Applicants' Specification pg. 57-58, If [0159]. 

Once the HTTP request is received at server 28-1, the server 28-1 will initiate the 
appropriate steps, or make the appropriate function calls, within the context of the API on the 
middle tier server 40, as indicated in flow line 234. The step further involves communication 
236 between the middle tier server 40 and the database 44. Flow line 236 illustrates the steps in 
which the middle tier server 40 obtains the requested information from or stores instructions into 
the database 44. One manner for doing so is the JDBC (Java DataBase Connectivity, otherwise 
known as the Java™ database API) wherein raw data is sent from the middle tier server 40 to 
database 44. The database 44 will return the requested data preferably, although not required, in 
a raw format to the middle tier server 40 as indicated by flow line 238. Applicants' Specification 
pg. 58, 1| [0160]. 

The middle tier server 40 assembles the retrieved data and updated information into 
formatted data, which are forwarded 240 to the web server 28-1 . It is noted that the API on the 
middle tier server 40 includes that programmable logic to package (i.e., format) data received in 



a raw format into a form that is well-suited for flexibly defining data structures. One format that 
is advantageous is XML because it allows the tagging of data in a manner that is not tightly 
coupled together, thereby providing more flexibility in defining data structures. Other formats, 
though, will work suitably well with the described embodiments of the present invention, 
including HTML. Applicants' Specification pg. 58, If [0161]. 

The middle tier server 40 enables communication between various web portals 28-1 . . .28- 
n and the database 44 through an API, which facilitates the communication of user instructions 
and operations for controlling the DVR 37 with the front end 14a. One technical advantage of 
the API is that it allows a portal (e.g., 28-2) to cache information received from the middle tier 
server 40 locally within the environment of the particular portal such as 28-2 with a frequency 
based upon when a user is interested in the information. Furthermore, the API of the described 
embodiment of the present invention is flexible so as to permit a portal 28-2 to present the 
content of information from the middle tier server 40 in a manner that enables display of 
information using proprietary types of graphical user interfaces (i.e., GUIs) distinctive to those 
system administrators operating the particular portal (e.g., 28-2). Business logic (e.g., checking 
of time conflicts for recording disk space) may be included in the middle tier server 40 to form a 
part of the API that provides a standardized mechanism for receiving request forwarded from the 
portals 28-1 . . .28-n, and for sending back a corresponding response. 

In order for the web server 28-1,. .., 28-n such as portal 28-2 to present the interactive 
television device data a the web browser 20, each web portal is enabled to use, copy , encode, 
store, archive, distribute, transmit, modify, translate, render into an audible format, publicly 
display and publicly perform the content received from database 44, in while or in part in 
connection with the property of the web portals 28-1, . . ., 28-n. The API enables the web portals 



to allow users at the browser 20 to download and print or perform the content. This content 
includes the interactive television device data, like for example, a top watched shows list. The 
API of the described embodiments of the present invention permits the content to fit the format 
and look-and-feel of the particular web portal. Applicants' Specification pg. 59-60, Tf Tf [0162, 
0163]. 

Applicants' FIG. 16B illustrates on a high level how a web server, e.g., portal 28-2, may 
utilize the API routines to access and manipulate data in the databases 268 in response to various 
user requests 260 in accordance with one embodiment of the present invention. Note that 
database 44 in FIG. 2 and in FIG. 5 is merely illustrative, and that the embodiment shown in 
FIG. 16B, which illustrates four databases 280, 282, and 284 and 286 each of which will be 
described below, works suitably well. The API routines 264 shown in FIG. 16B are designed to 
extract data from and to insert instructions into the databases 268. The predominant directions of 
data flows are indicated in the figure by the directions of the arrows connecting each routine to 
one or more databases. However, some parameters or exchange of triggering data is presumed to 
have occurred before any substantial amount of data is transferred to or from the databases 268. 
The database 280 contains information related to the user and comprises, for example, a replica 
of a commercial authentication database such as SilkNet™ and additional user profile data. This 
database is accessed by the API routines CreateAccount 288, Login 290 and GetProfile 292 that 
together authenticate a user and initialize communication between the user and the systems 10A 
and 10B, through the server 28-1 and the middle tier server 40. The box profile database 282 
archives information related to individual media-based devices, including the respective channel 
lineups. This database 282 is accessed by GetProfile 294 as well as GetChannelLineUp 296 in 
response to a user request to view information related particularly to the DVR 37 that the user 



wants to operate. The EPG database 284 may either be a commercial database such as an online 
service 54 or a database containing already extracted information from a commercial source. 
This database 284 is accessed by GetEPG 298 and ShowGuide 300 to retrieve program 
information. The box transaction database 286 includes information related to programs 
recorded by the DVR 37 and requests for the DVR 37 to record future programs. This database 
286 exchanges information with the middle tier server 40 every time a request is made through 
the AddRequest routine 304, or DeleteRequest routine 3006. It is also accessed in response to 
user request to view related information through GetReplayGuide 302. Applicants' Specification 
pg. 6 1-62, If [0166]. 

Applicants' presently claimed invention is expressly directed to a computer-implemented 
method for enabling a user to remotely control a media based device and to access related 
information from a web portal and an API that is located remotely from the web portal. 
Applicants' API permits data retrieved from a database to fit a format associated with the web 
portal. Specifically, Applicants' presently pending claims are directed to an API that is located 
remotely from the web portal and that permits the content to fit the format and look-and-feel of 
the particular web portal. Applicants' Specification pg. 59-60, Tf Tf [0162, 0163]. 

For example, Independent Claim 1 expressly recites the step of "providing an Application 
Program Interface (API) located remotely from the web portal that, in operation, permits data 
retrieved from at least one database concerning the media-based device to fit a format associated 
with the web portal." The remaining Independent Claims, Claims 35, 58, and 60 recite similar 
limitations. 

B. Barton 791 Does Anticipate Applicants ' Presently Claimed Invention 

Barton 791 does not anticipate Applicants' presently claimed invention. Unlike 



Applicants' presently claimed invention, Barton 791 does not teach or suggest to an API, let 
alone an API located remotely from a web portal. Naturally, therefore, Baron 791 fails to teach 
or suggest an API located remotely from a web portal that permits the content to fit the format 
and look-and-feel of the particular web portal. 

Rather, Barton 791 appears generally directed to a system and method for remote access 
to personal television service. According, to Barton 791, a user may access to the personal TV 
service center through a remote computer terminal or a personal digital assistant which is 
connected to a computer network. Barton 791, Abstract. The system of Barton 791 appears to 
utilize a Personal TV Service Center that includes a Web Server 200, a Program Database 
85/210, a User Database 220, and an Event Database 230. A Web Browser interacts with the 
Personal TV Service Center. See, e.g., Figure 2 of Barton 791. This system of Barton 791 does 
not utilize an API let alone an API located remotely from a web portal. 

According to the presently pending Office Action, Barton 791 teaches Applicants' 

"Application Program Interface (API))" relying on the following of Barton 791 : 

Figure 5, the GUI 500 for program selection and is used both on the DVR front 
panel and is incorporated into the Web pages and is used both on the DVR front 
panel and is incorporated into the Web pages presented to remote users by the 
Web server 200, [0044], [0051]-[0056] that, in operation, permits data (the 
program guide) retrieved from at least one database (Figure 2, 3, User database 
220, [002]-[0032]; Figure 4, in step 440, the web server presents program guide to 
the user after the user is identified and authenticated, [0048]) concerning the 
media-based device to fit a format associated with the web portal (Figures 5, 6, 
[0051]-[-56]. 

September 27, 2007 Office Action at page 3. Applicants respectively traverse. The Barton 791 
GUI (Graphical User Interface) is not an API, let alone Applicants' presently claimed API. 

As Applicants' describe in detail above, Applicants' API is not located in the web portal 
but remotely, in a middle tier server 40. As Applicants describe, in one preferred arrangement, 



once the HTTP request is received at server 28-1, the server 28-1 will initiate the appropriate 
steps, or make the appropriate function calls, within the context of the API on the middle tier 
server 40 , as indicated in flow line 234. (emphasis added). The step further involves 
communication 236 between the middle tier server 40 and the database 44. Flow line 236 
illustrates the steps in which the middle tier server 40 obtains the requested information from or 
stores instructions into the database 44. One manner for doing so is the JDBC (Java DataBase 
Connectivity, otherwise known as the Java™ database API) wherein raw data is sent from the 
middle tier server 40 to database 44. The database 44 will return the requested data preferably, 
although not required, in a raw format to the middle tier server 40 as indicated by flow line 238. 
Applicants' Specification pg. 58, Tf [0160]. 

The middle tier server 40 assembles the retrieved data and updated information into 
formatted data, which are forwarded 240 to the web server 28-1 . Applicants have noted that the 
API on the middle tier server 40 includes that programmable logic to package (i.e., format) 
data received in a raw format into a form that is well-suited for flexibly defining data structures. 
One format that is advantageous is XML because it allows the tagging of data in a manner that is 
not tightly coupled together, thereby providing more flexibility in defining data structures. Other 
formats, though, will work suitably well with the described embodiments of the present 
invention, including HTML. Applicants' Specification pg. 58, Tf [0161]. 

The GUI (Graphical User Interface) taught in Barton 791 appears to be some type of 
graphical interface that allows a user to enter information into a device. An API, on the other 
hand, is an application programming interface that allows one computer program to 
communicate with another such program. As just one example, an API is an interface that 



allows web browsers or web servers to communicate with other programs. Applicants make 
clear this distinction in their Specification. 

For example, as Applicants explain, the middle tier server 40 enables communication 
between various web portals 28-1 . . .28-n and the database 44 through an API, which facilitates 
the communication of user instructions and operations for controlling the DVR 37 with the front 
end 14a. One technical advantage of the API is that it allows a portal (e.g., 28-2) to cache 
information received from the middle tier server 40 locally within the environment of the 
particular portal such as 28-2 with a frequency based upon when a user is interested in the 
information. Furthermore, the API of the described embodiment of the present invention is 
flexible so as to permit a portal 28-2 to present the content of information from the middle tier 
server 40 in a manner that enables display of information using proprietary types of graphical 
user interfaces (i.e., GUIs) distinctive to those system administrators operating the particular 
portal (e.g., 28-2). Business logic (e.g., checking of time conflicts for recording disk space) may 
be included in the middle tier server 40 to form a part of the API that provides a standardized 
mechanism for receiving request forwarded from the portals 28-1 . . .28-n, and for sending back a 
corresponding response. Applicants' Specification pg. 58-59, Tf [162]. 

In an effort to further clarify Applicants' presently claimed invention, independent claim 
has been further modified to specify that the API is not part of the web portal but rather "located 
remotely from the web portal." All remaining independent claims recite a similar limitation. 

To anticipate a claim, "each and every element set forth in the claim [must be] found, 
either expressly or inherently described, in a single . . . reference." Vergall Bros. V. Union Oil 
Co. of California, 814 F.2f 628, 631 (Fed. Cir. 1987) (M.P.E.P. Section 2131). Consequently, 
since Barton 791 does not teach or suggest utilizing an API, Barton 791 also does not teach or 



suggest an API that permits the content to fit the format and look-and-feel of the particular web 
portal. Barton 791, therefore, naturally does not teach or suggest an API located remotely from 
any type of web portal. As such, Barton 791 simply also does not teach or suggest every element 
of the claimed invention and, therefore does not anticipate Applicant's presently pending 
Independent Claims. 

Consequently, Independent Claims 1, 35, 58, and 60 are allowable for at least all of the 
reasons stated above. The remaining claims are all dependent on these allowable independent 
claims and are therefore allowable for at least the reasons stated above. 

If there are any matters that may be resolved or clarified through a telephone interview, 
the Examiner is respectfully requested to contact Applicants' undersigned representative at (312) 
913-0001. 

IV. SUMMARY 

Applicants respectfully submit that, in view of the remarks above, the present application, 
including claims 1-3, 5-20, 35-37, 58 and 60-75 is in condition for allowance and solicit action to 
that end. 

If there are any matters that may be resolved or clarified through a telephone interview, 
the Examiner is respectfully requested to contact Applicants' undersigned representative at (312) 
913-0001. 

Respectfully submitted, 

McDonnell Boehnen Hulbert & Berghoff LLP 



Date: February 6, 2008 



By: /Thomas E. Wettermann/ 
Thomas E. Wettermann 
Reg. No. 41,523 



